创新｜什么才是一个真正的数字产品团队(上)

本文主要针对的一些传统的大公司/企业在构建自己的数字化产品需要考虑的数字产品团队架构建设。对于互联网公司，可能在团队整体建设上没什么问题，但是在原先没有数字基因公司来说，在公司原有的架构上搭建一个数字化团队却是困难重重。不是说组建了一个团队，里面有一个所谓的产品经理、设计师和开发便是一个产品团队。目前在拜耳以及我之前工作过的公司Cisco均有类似的问题。我到现在依旧记得当时我在Cisco和程度员讨论完一个需求后，我们都不约而同的问了一句话“产品经理在这个过程中有啥用？”

本人目前在公司正在进行与此相关的项目，偶尔间读到这篇文章，觉得作者Martin Cagan（前ebay副总裁，现硅谷产品联盟管理合伙人）将这个话题讲的特别透彻，因此翻译并分享各位正在数字化路上公司与团队。

（以下为文章翻译）

这篇文章肯定会让很多人感到不满。

对此我感到抱歉，但科技公司产品角色周围持续存在的噪音和混乱程度却一直在变得更糟。此外，我看到这些问题和有问题的行为正被制度化地呈现在会议演讲、培训课程和所谓的产品人员认证计划中。

我在过去多次谈到过这个问题，尤其是在关于被赋能产品团队（empowered Product teams）的文章和主题演讲中。然而，很多人只听到他们想听的，我意识到我需要更加明确地表达。

因此，虽然这篇文章读起来可能很痛苦，但如果你对产品世界里人们发出的自相矛盾、令人困惑的信息感到沮丧，如果你能在这里忍受一下，我希望这篇文章能提供一些急需的澄清。

在科技世界中，大致上有三种不同类型的“产品团队”。

就纯数量而言，最常见的团队并不是真正的产品团队，而是交付团队。也被称为“开发团队”或“Scrum团队”或“工程团队”，如果你的公司正在运行SAFe之类的东西，那么不幸的是这就是你。在这种情况下，有一些开发人员和一个产品负责人。在这个模型中，产品负责人是我所说的“待办事项管理员”。确实需要有人来做这些行政工作，但这完全是为了交付产出，与我所关心的代表客户进行真正、持续创新的需求关系不大。我已经在其他地方写过为什么这个模型实际上只是重新包装的瀑布模型，不会在真正的技术产品公司中使用。这个比较容易区分，我们暂且不谈。

这篇文章主要讲述另外两种团队之间的区别。

现在需要提醒一下，我将要介绍一些非标准的、当然也不被一致认可的术语。但是我必须这样做，因为如今作为一个行业，我们将另外两种团队都称作“产品团队”或“小队”。但是你会发现，虽然它们在表面上看起来相似，但它们在很多方面有着截然不同的特点，特别是在谈论产品经理的角色时。

当我谈论被赋能的产品团队的优点时，我指的是我在这里将继续称之为产品团队。具体而言，它们是跨职能的（产品、设计和工程）；它们专注于并根据结果进行衡量（而不是产出）；并且它们被赋能找出解决它们被要求解决的问题的最佳方法。

从这个意义上说，产品团队的目的是以客户喜欢的方式解决问题，同时又能为我们的业务服务。

尽管我可能希望不同，但我知道只有很少一部分团队是这种意义上的产品团队。更多时候，团队根本没有被赋能。相反，他们在那里只是为业务服务。

在本文中，我将把这第三类团队称为“功能团队”（feature teams）。在这里，我稍微偏离了功能团队的既定定义，但我之所以使用这个术语，是因为它有助于强调这些团队都是以产出为目的的。功能，偶尔也包括项目。这些通常以优先级列表的形式提供给团队，该列表被称为路线图。

但是这就是我们需要深入了解的地方。

请回想一下，在产品中总是存在四种风险：

• 价值风险（人们会购买它，或选择使用它吗？）

• 可用性风险（用户能否弄清楚如何使用它？）

• 可行性风险（我们能用现有的时间、技能和技术建造它吗？）

• 业务可行性风险（这个解决方案是否适用于我们业务的各个方面？）

在被赋能的产品团队中，产品经理明确负责确保价值和业务可行性；设计师负责确保可用性；技术领导负责确保可行性。团队通过真正的协作，进行交流和互动，以发现适合我们所有人的解决方案。

当我在文章中谈到，要成为一个被赋能的产品团队的产品经理是多么艰难，这正是因为要确保价值和业务可行性是非常困难的。

然而，在一个功能团队中，你仍然（希望如此）有一个设计师来确保可用性，你有工程师来确保可行性，但是，这一点至关重要：路线图上的功能（feature）的价值和商业可行性是请求该功能的利益相关者或高管的责任。

如果他们说他们需要你构建某个功能X，那么他们相信功能X将提供一定程度的价值，并且他们认为功能X是对业务/商业可行的。 

值得指出的是，即使利益相关者是隐含的价值和业务可行性的责任人，如果他们希望实现的结果没有实现，他们则会找到一种方式来责怪你和你的团队。用时太长，设计不好，为了达到日期而削减了关键功能等等。当然，你的团队可能从一开始就没有被说服这是值得做的。这是一个老问题了。

表面上看，功能团队和被赋能的产品团队都是产品团队。因此，它们看起来相似，但差异深远。

让我们从产品经理的角色谈起。  在一个被赋能的产品团队中，产品经理需要确保产品的价值和业务可行性，因此对客户、数据、行业，尤其是业务（销售、营销、财务、支持、法律等）的深入了解是绝对不可或缺的。

然而，在功能团队中，这些知识（充其量）分散在利益相关者中。

无论如何，希望大家都能明白，在这种模式下，产品经理的职责与功能团队是截然不同的。

功能团队的产品经理的工作最常被描述为一种促进者，为了设计和交付功能而“驱赶猫咪”，或者是一种模糊而薄弱的跨职能领导者，没有真正负责任何具体的事情。这些功能团队经常认为他们正在进行产品发现，但实际上只是做设计，可能还有一点可用性测试。

但功能团队对产品经理角色的影响还有其他方面。

由于团队没有被赋能--说白了，当你被产出时，你就没有任何意义上的赋能--因此很难吸引和留住真正的产品设计师（精通服务设计、交互设计、视觉设计和用户研究的人）。

在功能团队的绝大多数情况下，设计师（如果有的话）都是平面设计师。  这并不是说平面设计或视觉设计不重要，但与此相关的是，现在出现了一个很大的断层--至少需要有人负责交互设计，并希望能做一些用户研究。  因此，在这种模式下，产品经理面临着填补这些空白的压力是很常见的。

这种情况还会带来额外的负面影响，因为学习设计师使用的工具并不难，但学习如何做好设计和用户研究却很难。可悲的是，许多产品经理从未有机会与真正的专业产品设计师共事，因此他们甚至不知道自己错过了什么。

如果你有幸在你的团队中拥有一位真正的产品设计师（至少在他们离开去一家能够充分发挥其技能的公司之前），那么他们通常（也理所当然地）会质疑产品经理的目的是什么，因为对于他们来说，承担起功能团队产品经理的额外职责并不难，因为他们无论如何都在做大部分的工作。

结果就是，在功能团队中，产品经理的角色主要是项目经理，部分是（不熟练的）设计师。

工程师们往往也有类似的苦恼。  实际上是项目经理的产品经理往往与工程师认为他们需要的工作方式不一致。  更不用说，在这种模式下，工程师被降级为交付人员，正如我多次说过的，如果是这样的话，我们只得到了他们真正价值的一半（因此，优秀的工程师会再次希望离开，加入一个被赋能的产品团队，在那里他们可以真正实践自己的技艺）。

因此，当我写到产品经理需要 "跻身公司最优秀人才之列"、"首席执行官应将产品经理视为公司未来潜在的领导者"、"强大的产品经理就是产品的首席执行官 "时，我绝对不是在谈论功能团队的产品经理。

希望此时你已经知道自己是在功能团队模式下工作，还是在被赋能的产品团队模式下工作，但我了解到，人们往往不愿意承认自己是在功能团队模式下工作。

原文链接：https://www.svpg.com/product-vs-feature-teams/